Preparing OpenBSD for Deployment
=Introduction= You might be asking yourself "Why would I want to do this, when OpenBSD is so easy to install?" The fact is that no OS is better prepared for this sort of motion than OpenBSD - the kernel is so well written that you could take an image from a machine and move it to a different one - provided that OpenBSD supported it - and all you'd have to change is the interface names (and probably also some parts of the X config, but that's easy enough to do). This means that, if you have to provision a large number of servers, all the same hardware (say, a couple of dual rack mounted Soekris net5501 boxes), it can be a real time saver. =Ingredients= # One machine for the initial profile # Another machine to profile onto # An OpenBSD CD. =Method= For the purposes of this guide, we will be building a group of rack-mounted redundant firewalls. The firewalls have two CARP groups - one for the internal network (192.168.11/24) and one for the WAN (192.168.252/24). Between them are a pair of bridged ports used for pfsync. Each one is named dcrt''xx'', where xx is the number of the router. The script is based on a group of VMs I made to test this - replace vic with the interface used by the NIC on the Soekris. #!/bin/sh echo -n 'Router sequence no: ' read seqno echo -n 'LAN CARP password: ' read lancarppass echo -n 'WAN CARP password: ' read wancarppass advskew=$((seqno * 63)) advskew=$((advskew - 63)) echo "inet 192.168.11.254 255.255.255.0 192.168.11.255 vhid 1" \ "pass $lancarppass carpdev vic1 advskew $advskew" > etc/hostname.carp0 echo "inet 192.168.252.14 255.255.255.0 192.168.252.255 vhid 2" \ "pass $wancarppass carpdev vic0 advskew $advskew" > etc/hostname.carp1 printf 'dcrt%0.2d\n' $seqno > etc/myname printf 'inet 10.255.255.%d 255.255.255.248' $((seqno + 248)) > etc/hostname.vic3 Put this script in the root filesystem, and create an /etc/boot.conf file with the following, to force the system to boot off the ramdisk on boot: boot /bsd.rd The script above will delete this file once it is set up. To execute it on the system, you will need to chroot into the root filesystem to run it as the ramdisk lacks some of the required items to make it work (assumes wd0a is the root filesystem device and the script is named "reconfig"): mount /dev/wd0a /mnt /mnt/usr/sbin/chroot /mnt ./reconfig From there, just answer the questions you set aside for it and the script will do the rest. =Possible Applications= Redundant firewalls As I have shown, it is a good way to set up a set of redundant firewalls, which have a common set of settings and share firewall rules via pfsync anyway. Redundant load balancers Load balancers running on something like HAProxy would benefit greatly from this level of deployment, especially if they use CARP and pfsync for redundancy. In the latter situation you could share the config file via NFS and use control files to handle coordinated HUPs to reload the config whenever you add another web server to the pool. Redundant web servers This wouldn't be ideal for CARP based load balancing, but for servers behind a reverse proxy like HAProxy this would be ideal. Store all of your web data on a SAN exporting NFS and you're set. =Disclaimer= (or: My Lawyer Made Me Do It) This info is provided as-is, with no warranty, implied or otherwise, for its usability or suitability to your purpose. You agree not to hold the author of the article, the coders of OpenBSD or anybody who suggested this article to you if following these instructions causes you or anyone you know and love harm including, but not limited to: causing your computer to melt, your car to break down or your cat to go crazy and scratch your furniture to shreds. Finally, if it breaks, you get to keep both pieces. That, of course, is what it's all about.